Figure
1 The PowerLoom GUI
PowerLoom GUI Users' Guide
Eric Melz
The PowerLoom® GUI is shown in Figure 1. The main application frame consists of pull-down menus, a toolbar, and a status bar.
Figure
1 The PowerLoom GUI
KB - The KB menu contains menu items for connecting to a server, loading, saving, and clearing KBs, and opening browser and console windows.
Edit - The Edit menu contains items for cutting, copying, pasting, and deleting, and also contains an item which opens a preferences dialog.
Objects - The Objects menu contains items for opening editors on various KB objects, including modules, concepts, relations, instances, and propositions. This menu also contains an item to edit the currently-selected object.
Query - The Query menu contains items for querying the KB, searching the KB, and editing a relation's extension.
View - The View menu contains various items for updating the appearance of the application, including a refresh item to bring the GUI up-to-date with the state of the KB on the server, and menu items for showing/hiding the application's toolbar and status bar. This menu also contains items for changing the application's font – the demo theme changes all fonts to a large bold font suitable for demo presentations.
Navigate - The Navigate menu contains items for navigating backward and forward in a browser's selection history.
Window - The Window menu contains a list of the currently open windows on the desktop. Selecting a window brings the window to the top of the window stack, and if the window is iconified, it is de-iconified.
Help – The help menu contains an item to open an HTML help browser, and an item to open an About box which contains information about the PowerLoom GUI.
Most menu items have accelerator keys which allows an item to be executed by a combination of keystrokes. The detailed operation of each of the menu items will be elaborated further in the GUI Features section.
The toolbar contains several buttons which provide shortcuts to menu items. There are currently toolbar buttons for cutting, copying, pasting, deleting, editing an object, and opening a query dialog. The toolbar may be undocked from its default position by dragging it anywhere on the desktop. It may also be hidden by selecting the View -> Hide Toolbar menu item.
The status bar at the bottom of the application contains information on the current status of the application. The status bar is divided into two sections. The leftmost section displays the last module that was selected by a user. The application keeps track of the current module in order to provide continuity between operations. For example, if a user opens a browser and browses the AIRCRAFT-KB, and then opens a query dialog, it makes sense for the query dialog to use the AIRCRAFT-KB module instead of some other module.
The rightmost section of the status bar contains messages that pertain to the current state of the application. For example, if a user selects a concept and then clicks the cut toolbar button, a message will appear in the rightmost status bar prompting the user to select another concept and perform a paste action. The status bar may be hidden by selecting the View -> Hide Status Bar menu item.
Figure 1 shows a few internal frames that are open. The function of each frame is identified in the frame's title bar, and each type of frame has a unique icon in it's upper lefthand corner. In this example, the three open frames are used to browse the KB, query the KB, and edit an instance, respectively.
A user typically follows a workflow cycle similar to the following sequence:
The user launches the GUI by clicking on a hyperlink, executing a shell command, or clicking on a desktop icon.
The GUI is loaded on the user's machine. If the GUI was launched via JWS, JWS may need to download the entire application or updates to the application before execution begins.
The GUI reads a preferences file stored in a default location on the user's local machine. If this is the first time the application is being executed, a default preferences file is used. The preferences file includes among other things the PowerLoom server that was last accessed.
If the preferences file contains the last-accessed server, it attempts to connect to the server and query the server for a description of the server's capabilities. If connection is successful, a browser window will open displaying the modules that are currently loaded in the server instance.
The user selects any KB files (s)he wishes to load, and instructs the server to load the file.
The user performs some browsing, querying, and editing of the loaded KB.
If any changes were made, the user saves the KB.
The user repeats steps 5-7 as needed, and then exits the application.
This section provides a detailed description of the features that are available in the GUI application. We describe general application-wide functionality as well as the functionality of specific components.
The first time the GUI is started, it will not attempt to connect to any server. To establish a server connection, the user must select the KB -> Connect to Server menu item. This will open a dialog prompting for a host name and port. After the user enters this information, a connection will be attempted. If the connection is successful, the server information will be stored in the preferences file and used next time the application starts up.
A preferences dialog can be opened by selecting the Edit -> Edit Preferences menu item. Currently, the only preference that a user can edit is whether or not open a browser when the application is started. The dialog contains a checkbox asking whether or not the preferences should be saved. If the checkbox is not checked, the preferences will remain in effect for the duration of the current session, but will not be in effect when the application is restarted.
PowerLoom persists knowledge bases via flat files. The GUI has two options for loading and saving KB files. The first option is to load/save files using the local file system, i.e., the file system that is immediately accessible to the user. This option only works if the PowerLoom server has access to the same file system as the user. For example, this might be true if the server was executing on the same LAN as the user's machine. The second option is to load/save files using the file system that is visible to the PowerLoom server. This option would be used in situtations where the user is executing the client on a machine that is not immediately accessible to the server, e.g., over the internet. Since there are significant security risks with this option, this option is disabled by default. It can be enabled by setting a flag on the server indicating that remote file browsing is permissible. In order for this feature to be usable in practice, we would have to singificantly enhance the security capabilities of the PowerLoom server and the GUI.
The knowledge browser window, shown in Figure 2, can be opened by the selecting KB -> Browse menu item or typing CTRL-B. The browser provides a visual overview of all knowledge in the KB, and is capable of launching specialized tools such as editors, search dialogs, etc.
Figure
2 Knowledge Browser
There is one navigation pane for each type of KB object: Modules, Concepts, Relations, Instances, Rules, and Propositions. Each internal pane is resiziable by dragging the movable divider between the panes. Panes may be hidden completely by clicking the “collapse” arrow on the adjacent divider. Clicking the “expand” arrow will unhide the pane.
Navigation panes employ several visual cues to enhance the identifiability of object attributes. Object types are indicated by an icon to the left of the object's name. For example, modules are represented by a blue M, concepts by a red C, etc. The status of propositions is also indicated visually. An Italicized proposition indicates that the proposition was derived instead of asserted. Grey propositions indicate that their truth value is a default value instead of a strict value.
The main method for filling the contents of a navigation pane is to select some object in a navigation pane that is to the left or above it. This is discussed in more detail in the Selection section below. However, in some cases, it is possible to modify the contents of a navigation pane without performing a selection. For example, in the instance navigation pane, it is possible to show derived or inherited instances by right-clicking on the instance list and selecting an appropriate menu item. Similarly, the relation navigation pane can toggle between direct or inherited relations. Propositions and rules are by default displayed according to the module that is currently selected. However, the contents of the proposition or rule navigation pane can be updated by selecting a more specific module in the View From Module combobox contained in the navigation pane's title bar.
When the browser is initially opened, a tree of modules is displayed in the module navigation pane, and all other navigation panes are empty. When a module is selected, the remaining subpanes are populated with knowledge that is contained in that module. Similarly, selecting a concept in the concept navigation pane populates the relation, proposition, and instance panes with knowledge that is relevant to the selected concept. In general, selecting an object in a given navigation pane may affect the contents of navigation panes to the right and/or below it. More specifically, the rules for object selection are as follows:
Selecting a module populates the concept, relation, and instance subpanes with knowledge contained in the module.
Selecting a concept populates the relation subpane with relations that use the concept as a domain type, and populates the instance subpane with the concept's extension. The proposition and rule subpanes are populated with propositions and rules associated with the concept.
Selecting a relation populates the proposition and rule subpanes with propositions and rules associated with the relation.
Selecting an instance with no selected relation populates the proposition subpane with propositions that refer to the selected instance.
Selecting an instance and a relation populates the proposition subpane with propositions that contain the relation as a predicate, and the instance as an argument.
De-selecting an object will update the state of the browser appropriately. For example, after selecting a module and a concept, deselecting the concept will refresh the concept, relation, instance, proposition and rule subpanes to display the knowledge contained in the selected module.
The title pane in each navigation pane displays a description of the source of the subpane's contents. For example, if relation the relation WINGSPAN was selected, and the instance AGM-130 was selected, the proposition subpane would contain the title “Propositions for WINGSPAN and AGM-130”.
Each selection event is recorded in a selection history which can be rolled back and forward. For example, assume user selects the AIRCRAFT-KB module and then selects the GUIDANCE-TYPE concept. If the user then selects the Navigate -> Back menu item, the selection history will be rolled back so that only AIRCRAFT-KB is selected. If the user then selects Navigate -> Forward, the selection history will be rolled forward to its original state so that both AIRCRAFT-KB and GUIDANCE-TYPE are selected.
Knowledge can be explored by expanding and collapsing nodes in hierarchical navigation panes such as the concept and module navigation panes. If a tree or list is not fully visible, the user may use the scrollbar on the navigation pane's righthand side to scroll through the contents of the pane. Detailed views of objects such as concepts and relations can be obtained by right-clicking the object and selecting the Edit menu item. To navigate to the constituent of a proposition, the user can right-click the constituent and then select the Navigate to... menu item. For example, right-clicking on the GUIDANCE argument in the proposition (NTH-DOMAIN GUIDANCE 1 GUIDANCE-TYPE) presents a popup menu which displays (among other items) the item Navigate to GUIDANCE. Selecting this menu item will cause the browser to display and select the GUIDANCE relation.
Actions external to the browser may also update the browser's contents. For example, clicking on an instance in a list of query results will cause the browser to navigate to the selected instance.
Right-clicking inside the browser will present a menu of actions that is relevant to the subpane that contains the mouse pointer. The list of items will depend on whether the mouse is over a specific item or if it is over the background of the subpane's list or tree. For example, when the mouse is over a specific concept, the menu will contain items for cutting, pasting, instantiating, etc., but when the mouse is over the background of the concept's tree, the only menu item presented will be to add a new concept.
The set of actions for each subpane that is available for each subpane is as follows:
Module - Add Module, Edit Module, Load (Local/Remote), Save (Local/Remote), Clear, Copy.
Concept - Add Concept, Edit Concept, Edit Extension, Instantiate, Cut, Copy, Paste, Delete. If multiple concepts are selected, selecting Create New Concept from the background menu will create a concept that contains the selected concepts as parents.
Relation - Add Relation, Edit Relation, Edit Extension, Copy, Delete, Show Inherited/Direct Relations.
Instance - Add Instance, Edit Instance, Copy, Delete, Show Direct/Derived Instances.
Propositions - Add Proposition, Edit Proposition, Copy, Delete, Navigate to Constituent, Edit Constituent.
Rules - Add Rule, Edit Rule, Copy, Delete, Navigate to Constituent, Edit Constituent .
Objects may be edited by right-clicking the object and selecting the Edit item menu item in the popup menu. Alternatively, an object may be selected, and then the Objects -> Edit Object menu item can be selected, or the edit toolbar button can be pressed. Object editors do double-duty as object viewers, since all relevant information is present in the editor.
There are several common user actions that are available in edit dialogs. For example, hitting return while the cursor is positioned in the name field of the editor commits the concept. Most editors contain commit and cancel buttons at the bottom which can be used to either commit or abort edits. Lists of items commonly have a + and – button at the top of the lists, which repsectively mean add a new item, and delete the selected item. When the + button is pressed, either a chooser dialog (see the Choosers section) or a specialized editor will be opened. Like the browser, list items can be right-clicked to display a list of possible actions. For example, a superconcept can be clicked in a concept editor to immediately edit the concept's parent.
Each type of object has a specialized editor. For example, an instance editor is shown in Figure 3. There are separate editors for modules, concepts, relations, instances, and propositions/rules, which are described in turn below.
Figure
3 Instance Editor
The module editor contains a number of fields and components used to enter information relevant for a new or existing module. Examples of values that can be edited are a module's name, a module's documentation, and a module's includes list.
The concept editor allows editing of concept attributes such as a concept's supertypes, it's name, it's associated propositions, etc. In addition to the inherent attributes of a concept, all relations which have the concept as a domain type are displayed and may be edited. Clicking the + button above the relation list opens a new relation editor, with default values filled in. Similarly, clicking the + button above the proposition list opens a proposition editor.
The relation editor allows the user to input a list of variables and types for the relation's arguments, and allows the user to set various attributes for a relation, such as whether the relation is closed, functional, etc. Like the concept editor, propositions and rules associated with the relation can be edited.
The instance editor allows the user to input an instance's name, documentation, and associated propositions. If a proposition uses the relation image-url, an image will be retrieved from the server and presented in the editor window.
The proposition editor, shown in Figure 4, consists of a text field for entering the proposition, and a set of buttons for performing actions on the proposition. The buttons allow a user to assert, deny, or retract the typed proposition. There are several text-based facilities which support efficient editing of propositions. First, the editor supports many Emacs-style keybindings which facilitate editing of lisp-like expressions, including selecting entire parenthesis-delimited subexpressions, jumping backward and forward over subexpressions, and navigating up and down expression trees.
Figure
4 Proposition Editor
In addition to Emacs keybindings, the
proposition editor has a matching parenthesis highlighter. When the
cursor is placed before a left parenthesis, the matching right
parenthesis is is highlighted, and when the cursor is placed after
right parenthesis, the matching left parenthesis is highlighted.
The proposition editor also has support for symbol completion. The GUI uses a predictive backtracking parser to analyze partial input of propositions. Based on the analysis, the parser is able to recommend appropriate completions. For example, if the user types (f and then selects the completion action, the parser will recommend a list of completions including the forall symbol and all concepts and relations that begin with the letter f.
In a number of situations, an object of a specific type must be selected. For example, when selecting a superconcept in a concept editor, the user should be presented with a list of existing concepts. In these cases, a chooser dialog is presented to the user which displays a filterable list of candidate objects. As the user types a name of the object in the name text field, the list of objects is filtered so that only objects which begin with the typed prefix are displayed. Choosers are available for modules, concept, instances, and relations. A variable chooser allows the user to type a variable name and select a type from a concept from a list.
The extension editor, shown in Figure 5, allows editing of a concept or relation's extension, and can be opened by right-clicking on a concept or relation in the browser or by selecting the Query -> Edit Extension menu item. The extension editor presents a relation's extension as a list of tuples in table format. The user may add new tuples by typing names of instances at the bottom of the table, and may alter existing tuples but double-clicking on a table cell and typing in a new value. Instance name completion is available while typing instance names by typing CTRL – [right arrow]. A user may choose to abort the edited extension by clicking the Cancel button. If the user clicks the Commit button, the relation's extension will be updated by asserting and retracting appropriate propositions.
Figure
5 Extension Editor
The Query dialog, shown in Figure 6, can be opened by selecting the Query -> Query menu item, typing CTRL-Q or by pressing the query toolbar button. The Query dialog consists of a text area for typing the query, a results table for displaying the results of the query, a query list for selecting pre-saved queries, and an options subpane for configuring various query parameters.
Figure
6 Query Dialog
The query input pane supports features similar to that of the proposition editor, including Emacs keybindings, parenthesis matching, and completion. Queries can be executed by hitting CTRL-[RETURN] or by clicking on the Execute button at the bottom of the dialog. After a query has executed, results will be displayed in the results table or a “No results found” indicator will flash in the results area. The column headers for the results will display the corresponding free variables in the query. Results may be sorted by clicking on a column header. Doing so will sort the results by using the clicked column as an index. Users may toggle ascending/descending sort order by clicking the header multiple times.
If the query contains no free variables, it is effectively an ASK operation (as opposed to a RETRIEVE operation). In this case, the result will be a truth value, and the column header will be labeld TRUTH-VALUE. If the query is the result of a partial retrieve operation, an additional column containing the match score wil be displayed.
If the user clicks on a cell in the results table, the topmost browser will be updated to display the selected item. For cases where a partial query was performed, the user may right-click on a query result and select the “Show Explanation” menu item. Selecting this will present an HTML explanation in a separate window. The displayed explanation may contain hyperlinked objects. Clicking on a hyperlinked object will update the topmost browser to display the object.
Users may save frequently-executed queries in a query list by clicking the Save button at the top of the options panel. After clicking save, they will be prompted for a query name. Saved queries will be stored in the preferences file and are represented as XML. Saved queries are stored in the combobox to the left of the save button. Selection of a saved query will prefill the Query dialog with the query and all saved parameters.
All PowerLoom query options are available in the options dialog. These options currently include the query's timeout, moveout, maximum number of unknowns, minimum score, and match mode.
Figure
7 Search Dialog
Users may search by for objects in the KB by
entering strings which match the name of the object. A search dialog
as shown in Figure 7 can be opened by selecting the Query ->
Search menu item, typing CTRL-F, or by pushing a search toolbar
button inside the browser. If the user pushes a search toolbar
button inside a navigation pane, the search dialog will be configured
to search for objects associated with the type of object displayed in
the pane. For example pushing the search button inside the concept
navigation pane will configure the search dialog to look for concept
objects.
Searches may be constrained in several ways. First, the type of module may be specified or the user may specify that the search should be across all modules. Second, the types of objects to be searched is configurable. For example, users may search for concepts and instances, instances only, etc. Finally, users may specify that the objects name must match the beginning or end of the search string, or exactly match the search string.
When the user executes the search by hitting return or selecting the OK button, a list of results is presented. These results are presented in table format, where one column is the name of the retrieved object, another column contains the module that the object resides in, and the final column specifies the type of the object (i.e., concept, instance, etc). As is the case with query results, clicking on a search result item will update the topmost browser to display the selected object.
The console window, as shown in Figure 8, can be opened by selecting the KB -> Open PowerLoom Console menu item or typing CTRL-P. This opens an internal window which allows PowerLoom commands to be typed directly and sent to the PowerLoom server. The response generated by PowerLoom is sent back to the GUI and printed below the prompt. This functionality is similar to that of a LISP listener.
Figure
8 PowerLoom Console
The PowerLoom GUI supports Cut, Copy, Paste, and Delete operations. These operations can be used to edit text, and in some cases they can be used to edit objects in list or trees. For example, the concept hierarchy can be edited within the browser by selecting a concept, executing a cut operation, selecting another concept, and then executing paste. This sequence of operations will delete the concept from it's original position in the hierarchy, and make it a subconcept of the concept that was selected when the paste operation was performed.
We have implemented a robust data transfer framework which is capable of recognizing the types of objects that are being transferred, and the types of potential transfer sources and destinations. This allows the application to prohibit nonsensical data transfers such as cutting a concept in a concept navigation pane and then trying to paste it a module pane. It also allows data transfer operations to be context sensitive. For example, cutting a concept in a concept navigation pane means that a move operation is being initiated, while cutting a concept in a concept editor's superconcept list means that the concept should be removed from the list. Additionally, copying an object such as a concept, then executing a paste inside a text window will paste the name of the object.
As one would expect, text may be cut/copied/pasted between the GUI and outside applications.